
United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark OfTlcc 
Addioa: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria. Yiiginia 2231 3-1450 

WWW.Uj(pt0.gOV 



I ATTORNEY DOCKET NO. | CONFIRMATION NO. | 



APPLICATION NO. 



FILING DATE 



FIRSTNAMED INVENTOR 



09/817,670 

7590 

Eric Hughes 
1577 Rose Street 
Berkeley, CA 94703 



03/26/2001 

08/16/2005 



Eric Hughes 



EH-2001-01 



8660 



[ 



EXAMINER 



NALVEN. ANDREW L 



ART UNIT 



PAPER NUMBER 



2134 

DATE MAILED: 08/16/2005 



Please find below and/or attached an Office communication concerning this application or proceeding. 



BECEIVED 

• o»PE/«AP 

SEP 0 7 2005 



PTO-90C (Rev. 10/03) 




United States Patent and Trademark OrncE 



I APPLICATION Na | FILING PATE "J" 



FIRST NAMED INVEhTTOR 



09/817^70 03/26/2001 

7390 O8/2S/20O4 

Eric Hughes 
1577 Rose Street 
Berkeley, CA 94703 



Eric Hughes 



UNITED STATES OtFARTMENT OF COMMERCE 
United Stales Ps(ci*i uul Tr«lem«rk Office 

r oSSmISSIONER FOR PATCNTS 
P.O.Box 1450 . . 



I ATTORNEY DOCKET NO. | CONFIRMATIOW NO. [ 



EH.2001*01 



EXAMINER 



NALVEN. ANDREW L 



ART UNIT 



PAPER NUMBER 



2134 

DATE M A]LEE>: 08/25/2004 



J 



Please find below and/or attached an Office communication concerning this application or proceeding. 



RECEIVED 

SEP 2 3 2004 
Teclmology Center 2100 



PTO-90C (Rev. 10/03) 



Office Action Summary 



Application No. 

09/817.670 



Examiner 
Andrew LNalven 



Applicants) 

HUGHES. ERIC 



Art Unit 
2134 



- The MAiUNO OATE of this mmmunlca^on appoar^ on the cover sheet with the ctmspondenee addtess - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH{S) FROM 
THE MAILING DATE OF THIS COMMUNICATION, 

' Extensions o( (vne may be availatile under me pcovistons of 37 CFR 1 . i36(a}. In no evenl. tiowever, may ^ f^piy be timely filed 

after SIX ($) MONTHS from the matling <la(e of ttiis communicalion. 
. If the period for repTy speofied above is less than thirty (30) days, a raply wrilhin the statutory minimum of thirty (30) days win be consldeied timely. 

- »f NO period for reply is spodfied atx>ve. tfve maximum statutory period wr« appfy arwJ w8l oxpire SIX (6) MOMTHS from the-maittng date of iWs communtcation. 

- Failure to reply vvithin (he set or extended period for repty wit), by statute, cause Vhe appiication to become ABANDONED (35 U S C. § 1 33). 
Any reply received t>y ttie Office later than three months after the maifing date of this communication, even if timety fited, may reduce any 
earned patem lemt aidSustmant. See 37 CFR t. 704(b). 

Siatus 

1 )S Responsive to communlcation(s) filed on 26 March 2001 . 
2a){3 This action is FINAL. 2b)S This action is non-flnal. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the ments is 

closed in accordance with the practice under Ex parte Quayle, 1935 CO. 1 1 . 453 0,6. 21 3. 

Ofsposltton of Claims 

4) ^ Clalm(s) 1-20 is/are pending in the application. 

4a) Of the at>ove ciaim(s) Is/are withdrawn from consideration. 

5) D Clajm(s) is/are allowed, 

6) B Ciaim(s) 1-20 is/are rejected. 

7) 0 aaim(s) ts/are objected to. 

8) n Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) Q The specification is objected to by the Examiner. 

10)ISI The drawtng(s) filed on 26 March 2001 is/are: a}|S! accepted or b)D objected to by the Examiner. 

Applicant fnay not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

Replacement drawing sheet(s) induding the correction is required if the drawing{s} is objected to. See 37 CFR 1 .121(d). 
11 )D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12)0 Acknowledgment is made of a claim for foreign priority under 35 U.S,C. § 1 19(a)-(d) or (f). 
aOAII b)n Some *c)n None of; 

1 □ Certified copies of the priority documents have t>een received. 

2.Q Certified copies of the priority documents have been received in Application No. . 



30 Copies of the certified copies of the priority documents have been received in this National Stage 
appllcathn from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a fist of the certified copies not received. 



Attachment($> 

1) S Notice of References Cited (PTO-892) 

2} O Notice of Ofdftspefson's Pater^t Drawing Review <PTO-948) 

3) D InformaUon Disdosore St3tcn>eAt(s) (PTO-t449 or PTO/S8/08} 

Paper No<sVMail Date . 



4) Q interview Summary (PTO-413) 

Paper No(s)i/Mail Date. . 

5) O Notice of Informal Patent Application (PTO-152) 

6) □ Other: 



\).S. P»ten( and Ttadeinark 0(lit« 

PTOL-326 (Rev. 1-04) 



Office Action Sumntary 



Part of Paper NoTMail Date 20040818 



Application/Control Number: 09/81 7,670 Page 2 

Art Unit: 2134 

DETAILED ACTION 

1 . Claims 1 -20 are pending. 

Claim Rejections • 35 U$C § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U,S.C* 102 that 
form the basis for the rejections under this section made in this Office actbn: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or de$crit)ed in a printed publication In this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

3. Claims 1-2, 4-7, 9-14. and 16-19 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Kocher US Patent No. 5.903.651 . Kocher discloses a method for 
demonstrating and confirming the status of digital certificates and other data. 

4. With regards to claim 1 , Kocher teaches the arranging of a plurality of messages 
into an ordered sequence of messages (Kocher, column 6 lines 43-47 "data 

items... sorted in ascending order", column 11 lines 33-50). constructing a hash tree 
from the sequence of messages (Kocher, column 7 lines 19-26, hash tree), computing a 
value of a root node of a hash tree (Kocher, column 7 lines 51-64, root node), preparing 
a private key for a digital signature operation (Kocher, column 1 lines 46-50). and 
performing a cryptographic signature operation with the private key upon the value of 
the root node (Kocher. column 8 lines 5-13). 
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5. With regards to claims 2 and 1 3, Kocher teaches the tree constructed with a 
position dependent hash function (Kocher. column 7 lines 40-43, hash depends on level 
in the tree). 

6. With regards to claim 4. Kocher teaches a value of the leaves of the hash tree 
being taken as the results of a hash function applied to the values of the sequence of 
messages (Kocher. column 7 lines 33-44, cryptographic hash function). 

7. With regards to claims 5, 9, 1 1 and 18, Kocher teaches the perfonning of the 
cryptographic signature operation with padding added to the value of the root node 
(Kocher, column 8 lines 5-13, padding viewed as date/time stamp, number of nodes, 
see Figure 9 item 905). 

8. With regards to claim 6. Kocher teaches all that is described above, and further 
teaches the extracting of the public key digital signature from a combination of the hash 
tree and from the results of the cryptographic signature operation (Kocher, column 9 
lines 26-42). 

9. With regards to claims 7 and 19, Kocher teaches the incorporating of a hash tree 
size into the public key digital signature where the hash tree size is the number of the 
plurality of messages (Kocher. column 8 lines 5-13 ''number of nodes", see Figure 9 
item 904). 

10. With reganJs to claims 10, 12 and 17, Kocher teaches the parsing of the public 
key digital signature and the retrieving of its signature data (Kocher, column 8 tines 34- 
38, column 9 lines 26-36). the ascertaining that the signature data comprises a stated 
signature value and a stated sibling value and position sequence (Kocher. column 8 
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lines 29-32), cx)mputlng a hash tree branch comprising a leaf node and a root node 
(Kocher, column 10 lines 1-20, column 9 lines 39-44. Figure 14), the hash tree branch 
being computed with the value of the individual message and with the stated sibling 
value and position sequence (Kocher, column 9 lines 39-44)» and performing a 
verification operation on the stated signature value with the value of the root node and 
with the public key (Kocher, column 9 Kens 26-52). 

1 1 . With regards to claim 14, Kocher teaches the ascertaining that the signature data 
comprises a hash tree size (Kocher. column 9 lines 60-61 ), the detennining of a tree 
representative of the tree family and whether or not the shape of the hash tree branch is 
a valid branch of the tree (Kocher, column 9 line 53 - column 10 line 20). 

12. With regards to claim 16. Kocher teaches the value of the leaf of ttie hash tree 
branch taken as the result of a hash function applied to the value of the individual 
message (Kocher. column 7 lines 33-43). 

C/a/m Rejections * 35 USC § 103 



13. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for ail 
obviousness rejections set forth in this Office action: 

(a) A patent may not t>e obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the tinne the 
invention was made to a person having ordinary skill in the art to which said subject rrratter pertains. 
Patentability shaR not t>e negatived by the manner in which the invention was made. 



Application/Control Number: 09/81 7,670 Page 5 

Art Unit: 2134 

14. Claims 3, 8, 15, and 20 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Kocher US Patent No. 5,903,651 in view of Ostrovosky et al US 
Patent No. 5,123.045. 

15. With regards to claims 3, 8, 15. and 20. Kocher fails to teach the hash tree 
constructed using a hash function with a salt value. Ostrovosky teaches a hash tree 
constructed using a hash function with a salt value (Ostrovosky, column 6 lines 46-67). 
At the time the invention was made, it would have t>een obvious to a person of ordinary 
skill in the art to utilize Ostrovosky's method of hashing with Kocher's systenn because it 
offers the advantage of providing a random function that helps prevent attackers from 
corrupting memory locations (Ostrovosky, column 3 lines 28-57). 



Conclusion 

16. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

17. Simon et al US Patent No. 6,065,008 discloses a system for secure font subset 
distribution. 

18. Kaliski Jr US Patent No. 6,189,098 discloses a client/server protocol for proving 
authenticity. 

19. Ansper et at US PG Pub 2001/0032314 discloses a method for validating a digital 
signature. 

20. Karjoth et al US PG Pub 2001/0034839 discloses a method for secure 
transmissk>n of data and applications. 
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21 . Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Andrew L Nalven whose telephone number is 703 305 
8407. The examiner can normally be reached on Monday - Thursday 8-6, Alternate 
Fridays. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Gregory Morse can be reached on 703 308 4789. The fax phone number 
for the organization where this application or proceeding is assigned Is 703-872-9306. 
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Digital Signatures for Flows and Multicasts 

Chung Kei Wong, Siudcni Member, IEEE, and Simon S. Lam, Feilow, IEEE 



Absiracf — ^We present chaining techniques for slgnins^veiiiying 
muUiple psckct« using a noglc signing/verification operation. 
We then present flow signing and verification procedures based 
upon a tree-chaining technique. Since a single signing^rerification 
operation is amortized over inaoy packetf, these procedures 
improve signing and verification rates by one to two orders 
of magnitude, compared to the approach of signing/verifying 
paclcets individually. Our procedures do not depend upon reliable 
delivery of packets. They also provide delay-boonded signing, 
and are thus suitable for delay-sensitive flows, and multicast 
applications. To further improve our procedures, we propose 
several extensions to the Feige-Fial-Shamlr digital signatnre 
scheme to sttbstantially speed up t>otb the signing and veriflcatlaa 
operations, as well as to allow *^adJostable and incremental'* 
verificallon. The extended scheme* called eFFS, is compared to 
four other digital signature schemes (RSA, DSA^ EIGamat, and 
Rabin), We compare their signing and verification limes, as wett 
as key and signature sl/es. We observe that: 1) eFKS is the 
fastest in signing (by a large margin over any of the other 
four schemes) and as fast as RSA in verification (tie for a close 
second behind Rabin); 2) eFFS allows a tradeoff between memory 
and signing^vcrification time; and 3) cFFS allows adjustable and 
Incremental verification by receivers. 



D 



L INIRODUCIION 

ATA confidentiality» authenticity, integrity^ and nonre- 
^pudiaiion arc basic concerns ot' sccuritig data delivery 
over an insecure network, such as the Internet. Confidendaiiiy 
mean!» that only authorized receivers will get the data; au- 
ihendcity. an authorized receiver can verify Ihe idcniily of 
the data's source; inie^rity. an authorized receiver can verify 
that received data have not been modified; nonrepudiaiion^ an 
authorised receiver can prove to a third party the identity of 
the data's source.' 

Most investigations on securing data delivery over packet 
networks have focused on unicasi delivery of data sent as 
indepcndcnl packets. Bxceplions include recent papers on 
scalable secure multicasting {!), [13], {20J and a flow-based 
approach to datagram security [I4|. All of these papers are 
mainly concerned wiih data confidentiality. 

In this paper, our concerns are data authenticity, integrity, 
and nonrepudiatton for delay-sensitive packet flows, pailicu- 
larly flows to be delivered to large groups of receivers. For an 

Manuscript rvxrciveJ January 27, I9W; revised June U. 1^99; approved 
by ll:i:i{/ACM Transaituws m NrTv-URKiw; lidiior i, Crowcrort. Iliis 
work wu Kuppancd in pan by Texas Advanced Research Program under 
CiVMXK U0.Vr5K-O63 iiJut by ihe NSA INKOSt'C Uiivcniiiy Keward) Program 
umJci (iiaiit MIM9(M«VK*OAV0l. An earlier version ol" ihw paper appears 
in i'inct'fJunis tEEH /CM* ^H. 

i'hc ;]ulhurs arc wiiit (he t)cpan»ieni uf Conipufcr Scicnurs, itte 
Univi-jsily ,»r Tc%;is .ii AiiMuK Ausiii>. TX 7fi7IMIK8 USA (c-nwil; 
ckwiiinjiii^cuniputcr.arg: fanifMVS.uicxaj.cdul, 

Publisher Kcm Wctuificr S I06).66W>9)07274.X. 

* In the hjtaiicc ihis pajxT. we use "nrccivcr" lu niean "autlionxcd 
ivccivcr" uwXmss oitteru-isc Maicd. 



individual message (packet), these concerns can be addressed 
by one of many available digital signature schemes [6], (15]. 
[17], (191. However, these schemes' are not efficieot enough 
for signing/verifying packets individually for delay-sensitive 
flows, such as padcct video. 

In the Internet, multicast has been used successfully to 
provide an efficient, best-effbit delivery service to iaige groups 
[2]. Consider a packet flow multicasted to a group of receivers. 
A consequence of best-eflbrt delivery is that many receivers 
will not receive ail of the packets in the multicasted flow. 
Furthermore, many multicast applications allow receivers to 
have widely varying capabilities (e.g., to receive layered video 
and audto transmissions) or needs (e.g.. to receive difTerent 
stock quotes, news, etc.). Consequently, receivers gel different 
subsequences of packets from the same multicasted flow. 

A. Existing Techniques for Signing Flows 

Conceptually, a digital signature scheme is defmed by 
functions for key generation, signing, and vcrilieatton. The 
signer (sender) uses the key generation function to create a 
pair of keys, a signing key A:«> and a verification key k^* The 
signer keeps the signing key private, and makes the verification 
key publicly known to all verifiers (receivers).^ 

To sign a message m using signing key the signer calls 
file signing function which returns the signature of message 
m. The signer then sends the signed message, consisting of 
message m and its signature, to verifiers. Having received the 
signed message, a verifier calls the verification function with 
key fcv. If the verification function returns true, then the verifier 
concludes thai the signer did sign the message and the message 
has not been altered. Moreover, the signer cannot deny having 
signed the message (nonrepudiution). 

In practice, a message digest function, such as MDS [18], is 
first applied to the message to generate a fixed-size message 
digest which is independent of rne.ssage si/c. Signing a mes- 
sage means signing the digest of the message. (MDS message 
digests arc 128 bits long.) 

A flow is a sequence of packets characicrized by some 
attribute (16], (2 1 J. Packets in a flow may be obtained from 
segmenting the bit stream of digitized vidcu, digitized audio, 
or a large file. They may also be related data items, such as 
stock quotes, news, etc., generated by the same source. 

It is easy and cflicicnl to sign an aU-or-notbing flow, thai 
is, a flow whose entire content is needed before any part of it 
can be used. e.g.. a long file. In this case, the signer simply 
generates a message digest of the entire flow (file) and signs 
the mes.«sagc digest. 

' i'hc signing ;ind verincatiuii keys are also rercrrcti to jis private ami public 
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Most applicaiions, however, create flows that are not all-or- 
nothing. Thai is, a receiver needs to verify individual packets 
(or» more generally, application data units) and use them before 
the entire flow is received. For these flows, a straightforv/ard 
solution is to sign each packet individually and each packet is 
verified individually by receivers. This solution is called the 
sign-each approach. 

The sign-each approach is computationally expensive. The 
signing rate and verification rate are at most l/(T</(0 T^^) 
and l/(7i(/) + rvorify) packeis/s. respectively, where TJJ) is 
the time to compute the message digest of an /-byte packet, 
Tiign is signing time, and Typify is veHficalion time for the 
message digest of a packet The signing and verification rates.* 
in packets/s, of two widely used digital signature schemes, 
RSA (19}^ and DSA (I5|, with 5i2-bi't modulus and using 
100% processor lime of a Pentium fl 300-MHz machine are 
shown below: 



packet size Signing rate Vcriflcation rate 

(bytes) RSA DSA RSA DSA 

512 7H.8 176 2 ISO 128 

1024 78.7 175 1960 127 

2048 78.0 172 1620 126 



If a slower macliinc is used, or only a fraction of proces- 
sor time is available for signing/verification (e.g., a receiver 
machine has only 20% processor lime for venftcation because 
the oiher 80% is needed for receiving and processing packets), 
then the rales should be decreased proportionally. 

Tlx; signing rate is not important for a noifreal-iinw gener- 
ated flow, i.e.. a flow whose entire content is known in advance 
(such as stored video). This fs because packets in the flow can 
be signed in advance. For a real-time generated flow, however, 
the signing rale must be higher than tltc packet-generation rate 
of the flow. Furthermore, for delay-sensitive flows, reaMtmc 
generated or not, the verification rate is important. From the 
above table, we see that the signing and veriflcatton rates of the 
sign-each approach, using either RSA or OSA, are probably 
inadequate for many applications. 

Two techniques were previously pro|)osed for signing digital 
streams [7] which, at first glance, may be used for signing 
packet flows. To describe the technique in [7] for signing 
a nonreaNiime generated flow, consider a sequence of m 
packets. The sender first computes message digest X?,„ of 
packet m (the last packet) and concatenates packet m - i 
and Ah to fonn augntcnied packet ni - 1. Then, for i = 
1, • •• ,fii — 2, the sender computes message digest Dm~i of 
augmented packet rn-t, and concatenates packet rii- r - 1 and 
D,u-i to form augmented packet m — i — 1, Message digest 
D\ of augmented packet I is computed and signed. In this 
manner, only one expensive signing/verification operation is 
needed for the sequence of m packets. However, a necessary 
condition for using the above technique is the following ^cr- 
(di'lwfore requirement: To verily packet i in (he .sequence, a 

*Tf)c signing and vcritiution rvcs arc raics tor si'cning and verifying 
tlK-bit MtJS message digtsis of pacltci.s. 

In (his paper, wc u^c r: = 3 m KSA to obim its ra.>iiesi vcriitcaiion time 
wiihoiii anivting ils stgiiing lime. 



receiver must have received every packet from the beginning 
of the sequence. 

For a real-time generated flow» a similar tedmique is 
suggested in [7] vviih the same get-all-before requirement. 
For a sequence of rn packets, only one expensive sign- 
ing/venflcation operation is needed, plus one inexpensive 
one-time signature signing/veriflcation for each packet in the 
sequence. However, since one-time signatures and keys are 
very large, this technique has a large communication overhead 
(around 1000 bytes/packet) (9), [10]: 

The get-all-before requirement of both techniques in [7] is 
too strong for practical Internet applications. Reliable packet 
delivery is not used by many applications for flows and 
multicasts. For example, reliable delivery is generally not used 
for video and audio flows due to the extra delays associated 
with retransmissions: either losses are tolerated or forward 
error correction techniques are used instead. 

For large>scale multicast applications* reliable delivery of 
multicast packets is a difficult problem [5]. Moreover, even 
if reliable multicasting is available, receivers with different 
needs/capabilities may choose to get dtlferem subsequences 
of packets in a multicastcd flow. In short, the get-all-before 
requirement is not satisfied. 

B, Characteristics and Requirements 

We have observed various characteristics in the delivery of 
flows and multicasts by an unreliable packet network, such as 
the Internet. They are summarized below. 

• Each packet in a flow may be tjsed as soon as it is 
received 

• A receiver may get only a subsequence of the packets in a 
flow. Different receivers may get different subsequences. 

• Delay sensitive flows require fast processing at receivers. 
ReaUime generated flows require fast processing at 
senders as well. 

• For 8 multtcasted flow, many receivers are limited in 
resources (processing capacity, memory, communication 
bandwidth, etc.) compared to the sender, which is typi* 
cally a dedicated server machine. In some environments, 
both senders and receivers may be limited in resources, 
e.g., mobile computers using wireless communications. 

• Receivers may have widely dincrciit capabili- 
ties/resources. For example, receivers may be personal 
digital assistants, notebook computers, or desktop 
machines. Moreover, the resources available to a receiver 
for verifying signatures may vary over lime. 

Given the above characteristics, wc design procedures for 
signing and verifying flows in Section II, as well as a dig- 
ital signature scheme in Section Iff to meet the following 
requirements. 

• The signing procedure is cflicicm and, for real-time 
generated flows, delay bounded. 

• The veriflcation procedure is clflcicnt (since many re- 
ceivers have limited resources). 

• Packets in a flow are individually verifiable. 

• Piickci sigiutlures are small (i.e., small communication 
overhead). 
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• Adjmmble and incremental verification: The verification 
operation i$ adjustable to the amouni of resources a 
receiver has. It allows a receiver/verifier to verify a 
message at a lower security level using less resources, and 
laier inaease the security level by using more resources 
(e.g., if ihe message is importanl). 

C Contributions oj this Paper 

In Section !!» wc first describe and compare two chaining 
techniques (star and tree) for signing/verifying multiple pack- 
ets using a single signing/verification operation (without the 
gct-alUbcforc requirement in 1 7]). Wc then present flow sign- 
ing and verification procedures based upon the tree-chaining 
technique. Since a single signing/Vcrification operation is 
amortized over many packets, these procedures improve sign- 
ing and verification rates by one to two orders of magnitude 
compared to Ujc sign-each approach. The signing procedure 
also provides delay-bounded signing. Thus the procedures can 
be used for delay-sensitive flows. 

Since signed packets in our procedures are individually 
verifiable, the procedures can be used to reduce the workload 
of nffy machine that sends out a iarge number of signed pacitets 
to one or more destinations. There is no requirement thai these 
pack(?ts beiong to flows. However, for packets that belong to a 
flow, the workload of the flow's recciver(s) is also reduced. 

In Section Itl, we turn our attention to improving the signing 
and verification operations in the procedures. Specifically, wc 
present several extensions lo the Fcigc-Fiai-^Shamir digital 
signature scheme to speed up both signing and verification 
as well as to allow adjustable and incremental verification. In 
Section IV. the extended Feigc^Fiai-Shamir (eFFS) scheme 
is compared to four well-known signature schemes (6), II5|, 
[17]. [191. Wc compare their signing and verification limes* 
as well as key and signature sizes. We observe that; I) cFFS 
is the fastest in signing (by a large margin over any of the 
other four schemes) and as fast as RSA in verification (tie 
for a close second behind Rabin); 2) eFFS allows a tradcofiT 
between memory and signing/verification time; and 3) cFFS 
allows adjustable and incremental verification by ivceivers. 

II. How m Sign a Flow 

To digitally sign/verify delay-sensitive flows, the sign-each 
approach is computationally loo expensive for many applica- 
tions, particularly those applications that generate packet flows 
in real time. 

As «n alternative lo the Kign-each approach, we present two 
chaining technique.*; (sJar and tree) for providing authcnliciiy 
to a group of packets, called a bhck, using a single signing 
opcruiion. The basic idea is to compute a block digest which 
IS signed. In order to make packets individually verifiable, 
each packet needs to carry jts own authentication infonnaiion 
consiicing or the signed block digest {Mock signature) together 
wtth some chaining informaiion as proof that the packet is in 
the block. 

Star C/iaifiing 

Consider m packets thai const imie u block. In st;ir chaining, 
Ihe block digcsi k simply the mesjwge digest of the tn packet 




Fig. 1. Star-chaining icchniquc. 

digests (listed sequentially). Let h{ ) denote the message 
digest fiinciion being used (e.g., MD5). Consider, for example, 
a block of eight packets with packet digests I>i, 
The block digest is Oi^^ = MA. --.i^a), and the block 
signature 5i^(A-a} is the block digest signed with some 
digital signature scheme (such as RSA, DSa, or cFFS). 

The relationship between the packet digests and the block 
digest can be represented by a one-level rooted tree, called an 
authentication star. Fig. I illustrates an authentication star for 
eight packets, with packet digests at leaf nodes, and the block 
digest ai the root. 

For packets to be individually verifiable, each packet needs 
its own authentication information. Such authentication infor- 
mation, c^Wtd packet signature, consists of the block signature, 
the packet position in the block, and (he digests of all other 
packets in the block, (We use the tcmi chaining overhead to 
refer lo all information in a packet signature except the block 
signature.) 

Suppose the third packet in the above example is received. 
Its authenticity can be individually verifled as follows. The 
verifier computes the digest D'^ of the packet xecci^ad, and 
then the block digest D;^« = h{Di . D2 . /^i. i>4. • • • , Da), 
where Di.Dt, D^xr -^O^ are carried in the packet signature. 
The vcriflcr then calls the verification operation to verify ly^.^, 
i,c„ to determine whether is equal lo block digest Ox^^ 
in block signature sigti(Di^), The packet is verified if the 
verification operation returns true, i.e., i>i-a = Dj_«. 

Suppose the third packet is the first in the block to arrive 
and its authenticity has been verified. Afterwards, the verifier 
knows every node in the authentication star, i.e., all nodes in 
the authentication star arc verified and can be cached. With 
caching, when another packet in the block arrives later, say 
the sixth packet, the verifier only needs lo compute the digest 
/Jg of the packet received and compare it to the verified node 
Aj in the authentication star. If they arc equal, the packet is 
verified. 

B. Tree Chaining 

Tree chaining subsumes star chaining as a special case. With 
tree chaining, the block digest is computed as the root node of 
an authentication frftf.* Consider, for example, a block of eight 
packets with packet digests Di^ - Mh The packet digests 
arc ihc leaf nodes of a dcgrcc-two ibuuiry) aulhcniicaiion tree, 
with other midcs of the tree ccmipuicd as message digests of 

'Tree chaintng was first prcscntcil in ft l|. Any rooted iras can he usc«l as 
uii luthcottciititm tree witli packet digp^ts »t Icif nodes and tlic bludc digest 
at ilv rooi. in pantcubr. there is no need 10 use a balanced tree. 
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2. TreL--cbaiRing technique. 

iheir children, as shown in Pig. 2. For example, (he parent of 

the leaves Di and is Di2 = h(Di,D2), where ) is 
the message digest function being used. The root is the block 
digest, with the block signature being the signed block digest. 

For a packet to be individually vehfiabtc, each packet needs 
10 carry its own authentication information (packet signature). 
In tree chaining, a packet signature consists of the btock 
signature, the packet position in the block, and (he sibh'ngs of 
each nude in the packet's path to the root. (Again, wc use the 
term chaining overhead to denote all information in a packet 
signature except the block signature.) 

\ To verify a packet individually, a verifier needs to verify 
its path to the root. Consider, for example, the dashed path 
in Fig. 2 for the third packet. Each node in the path needs to 
be vcrihed. A verifier computes the digest of the received 
packet, and then each of its ancestors in the tree. That is» 
D'^, = /i(£^i.i>4), X>U = fi{Di^2.D':^h and PJ., = 
K^i^u^^fs), where D4,Di^z and D^s are carried in 
the packet signature. The verifier then calls tlic verification 
operation to determine whether D\^q is equal to block digest 
Di-s in block signature «yn(£>i_a). The packet is verified if 

y^e verification operation returns true, i.e., Oi_g = Di-a. ^ 
Suppose (he third packet is the first in the block to arrive. 
A Act verifying it, the verifier knows the following nodes* in 
the authentication tree: ^3, ^-t» A--2» ^a-a and 

the block digest £>i-.h. These arc verified nodes which can be 
cached. By caching verified nodes, the verifier only needs to 
compute each node in the auihenticai ion irce at most once. 

f'or example, aficr verifying the third packet, to verify 
the sixth packet which arrives later, the verifier computes 
the digest of the packet received ZJJ. its parent - 
h{Dr,,iy^), and its grandparent = h{£y^^Q, Dy^sl If 
^i-rt equal to the cached node Dj-si the sixth packet is 
verified. 

C. Comparison of Chaining Tfri hniifues 

Wc performed cxpcnniciUs on a Fcntium U lUO-MU/ ma- 
chine running Linux, and compared star and tree ctiaining. We 
used MDS as the message digest function [18] for geiwriiting 

*JSoiiic wc cjnicd in (he packci sigftatunr and (Iw oibcis have been 

CUIIlpUlCll. 
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Fig. 3. MDS computation time (mi^iseGcmds^ 



l2S-bit message digests. Fig. 3 shows the MDS compulation 
time versus input size. We observe that the MDS computation 
time can be regarded as a linear function in input size (for a 
large input, i.e., 1024 bytes or nwre). 

^ For each chaining technique, an authentication tree is first / 
built for a block of packets.^ i.e., each node is computed 1 
as the message digest of its children. The time to build ati^ 
Smtheniication tree (excluding time to compute packet digests 
for leaf nodes) is called the tree build lime. The block signature 
is then obtained by signing the block digest at the root. AAer 
that, the packet signature of each packet is built from the 
aulhentication tree and the block signature. The time to build 
a packet signature is called packet signature build time. The 
chaining time for a block at a signer is the sum of tree build 
time and packet signature build lime for all packets in the 
block. ^ Fig. 4(a) shows (he chaining time for a block of packets 
at a signer. 

Consider the total signing time for all packets in a block, 
which is the block's chaining time plus the signing time of 
the block digest. The btock digest signing time is 12.7 ms 
using 512-bil RSA and 5.6 ms using 5 12*bit DSA. For a block 
of 16 packets, from Fig. 4(a). Ihe chaining time is 0.21 ms 
for a degree-two authentication tree. The tout signing time is 
0.21 + 12.7 = 12.9 ms using 512>bit RSA. Thus, the average 
signing lime for one packet is 12.9/10 = 0.81 ms, which is 
less than 1/15 of the btock digest signing time using 512-bit 
RSA. 

To verify packets in a block, an autlienticalion tree is built 
from packet signatures as packets arrive. The chaining time 
for a block at a verifier is the sum of tree build lime and time 
to verify chaining information in the packet signature of every 
packci in the block.* Fig. 4(b) shows ihe chaining lime for a 
btock of packet.«i al a verifier w\(h caching of verified nodes. 

Consider the total verification time for all packets in a block, 
which is the block's chaining time plus the verification lime of 
(he block signature. TItc signature verification time is 0.40 ms 
using 512-bit RSA and 7.6 ms using 512-bit DSA. For a block 
of 16 packets, from Fig. 4(b), (he chaining time is 0.24 ms tor 
a degree-two authentication troc. The total verlDcdfton time is 

'Wc wiH use "ircc" instead iif "trcc.-siaf"* siiicc star chutnini; is a special 
cauf of (rcc ctuining. 

"Note \Um chaiKing itnic <iocs not include time (u cuinputc packet digests 
(w leaf nodes and liinc xo sign iIm; blocti digest. 

"Ntilc tlwt clutniiig ftttic docs <ioi iiwiudc time to compute paclcvl digests 
for leaf nodes and tiinc lo verify the block sigoaturc. 
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0.24 + 0.40 := 0,04 ms using 512-bil RSA. Thus ihc average 
vcriBcation lime for one paeket is 0.G4/1C = 0.04 ms, which 
is i/10 of the signature vciilicafion time using 5}2-b}t RSA. 

From Fig. 4{a), note that for any btocli si^ smaller than or 
equal to 64 packets* star chaining takes less time at a signer 
than tree chaining (degrees two to eight). However, for a larger 
block size, star chaining takes more time at a signer than tree 
chaining, because the chaining lime for a siar is O(m^) and 
the chaining lime for a tree is O(mlog(m)}, where r/i denotes 
block size. 

As showu in Fig. 4(b). star chaining takes less time at a 
verifier than tree chaining for all block %\Z'^%, 

For each chaining technique, a packet signature has two 
parts* the block signature and the chaining overtiead. In 
general, if a tree is not balanced and full, the chaining 
overhead sizes of different packets arc different. Fig. 5 shows 
the average chaining overhead size per packet. The size of llic 
block .'itgnalure is not included in fig. 5 since il depends on 
which ."Jignaturc .scheme is u.scd (e.g.. ihc block signature is 64 
byics lor 5 (2-bit RSA. and 40 bytes Ibr 512-bil DSA). 

From Fig. 5. note that the chaining overhead ofsiar chaining 
is much greater than tree chaining Ibr block sizes larger than 
eight. If a small communication ovcrliead is important, packet 
signature sizes should be reduced. We recommend ihc use of 
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degree-two tree chaining which requires the smallest chaining 
overhead. (From Fig. 4, a dcgree-two tree has a slightly 
higher chaining time than the alternatives, but the difference 
is insignificant because chaining time is much smaller than 
signing/verification time of Ihc block digest. See Figs. 7 and 
8 in Section ll-D.) 

D. Flow Signing and Verification Procedures 

A flow is signed by partitioning it into blocks of packets* 
with each block signed using tree chaining. For a nonreal- 
time generated flow, blocks are of the same size m, chosen 
to be a power of the autheniicaiton tree degree d. For a real- 
time generated floW| the packet generation rate is time-varying 
for many applications» such as compressed video and voice- 
activated audio. For these applications, partitioning (he flow 
into fixed'Size blocks may lead to an unpredictable (perhaps 
unbounded) signing delay. Instead, the flow is partitioned by 
fixed time periods, and packets generated in the same time 
period are grouped into a block (see Fig. 6). 

For both real-time and nonrcal-timc generated flows, the 
flow vcri^catton procedure is the same. For the Hrst received 
packet in a block, i.e.. the block signature carried in the packet 
signature is new to a verifier, the verifier computes the packet 
digest, and every ancestor of the packet digest.*** For the 
computed block digest (the root of authentication tree), the 
verifier calls the verification operation to verify that il is equal 
to the block digest in the block signature. If so verified, then 
all computed nodes and their children arc verified and cached. 

For a packet that is not the first received packet in a 
block, the verifier computes the packet digest. If the packet 
digest has been cached and the cached value is equal to the 

An ancestor node is cuntpulvd itte nics<iiigc digest uf its children whicfi 
arc ciilicr cumpuicd or corned in flic packet signalurc. 
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Fig. 7. rtow signing raic(packeu/$) for 1 024 -byte packtis. (i» Using S12'bit g veHftcatton rale (packets/s) for 1024^ytc packets, (a) Using 

USA. <b) Using 5l2*fait I>SA. 5(2'btt RSA. (b) Using SI2<bit DSA. 



computed packet digest, then the packet is veriHed. Otherwise, 
the verifier computes every noncached ancestor of the packet 
digest. For the highest noncached node computed, the verifier 
then computes its parent. If the computed parent and its cached 
value arc equal, the packet is verified and all computed nodes 
and their children are verified and cached. 

We implemented the How signing and verification proce- 
dures (see Appendix) and performed experiments on a Peniium 
If 300«Mllz machine running Linux. We used MD5 as the 
message digest function, and experimented with both 512* 
bit RSA and 5l2*bit DSA as the signature scheme for block 
signatures. 

Figs. 7 and 8 show, respectively, the flow signing and 
verification rales for 1024'byte packets.*' Note ihat tree and 
star chaining are one to two orders of magnitude more efficient 
than the sign-each approach. The flow signing and verification 
rates increase with block size. I lowevcr, the rates vary only 
siigiuly with the chaining technique used and with the tree 
degree in tree chaining. Since degrec-lwo tree chaining lias 
the lowest chaining overhead (packet signature size), we 
rccomntond the use of degree-lwo tree chaining. 

I'igs. 9 and 10 show, respectively, the flow signing and 
verification rales for packets of size 512, 1024, or 2048 bytes. 
We used dcgrcc-two tree chaining. From the figures, observe 

N^riricaiton rates wure computed assoming no packei loss. 



that (he flow signing and verification rates decrease as the 
packet size increases, ti is because more lime is needed lo 
compute ihe message digest of a larger packei. The decrease 
is more pronounced when the block size used is iargc« since 
more time is used to compute packet digests for a large block 
than a small block. Observe also that the flow signing and 
vcrificatbn rates increase with block size and (he increase is 
greater for a smaller packet sv/c. 

E, BatmM Delay Signin^^ 

Consider Fig. 6. Assume that, in period 1\ at most rn 
packets arc generated and their packet digests computed. The 
lime for signing a block of m packets is «!hiuu,(t») + 'i;„j„ 
where chHiu,(rn) is the chaining time for a block of m 
packets at a signer, and r^gn is the block digest signing time. 
Therefore, the delay of ai>y packet whhin the block is at most 
Dm = T + chain,(m) + T,i^n- 

Table I shows the delay upper bound D^ for period T = 50 
ms. Note that the upper bound is fairly insensitive to block 
.size since the block*s chaining lime is much smaller than ibe 
block digesi signing time. 

For a given application with a specified upper bound. D., 
for signing a real-time generated flovir at a known packet rate, 
we can work backward and derive an appropriate value for 
the parameter T needed for the signing procedure of a real- 
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time generated flow. Observe, from Fig. 6. that T must be 
larger than T«im) + ciiaiii«(m}, and must be larger than 
'iCiiigu + di4u«,(m)). 

F. St'lectinf* a Digital Signafun* Schvme 

For nonreaf-itme generated Rows» signing efficiency is not 
critical. Thus a signature scheme with an efficient verification 
operation, such as RSA, can be used in the How signing 
and venRcation procedures. For real-time generated flows, 
however, it is critical that both signing and verification arc 
highly cITicicnl. Furthermore, in choosing a digital signature 
scheme, wc mu.si i\\sio consider machine cnpabiliiics (sender 
and receiver), as well as the fraction of processor time avail- 
able for signing and vcrificaiion. 

Using 100% processor time of a Pcniium 11 300-Mllz 
machine, the flow signing and verification rates for 1024-byie 



packets, degree-two tree chaining, and block size 16 arc shown 
below: 



signing rate 
5 1 2'bii RSA 1090 packets/sec 
5 1 2-bil DS A 2 1 40 packets/sec 



verificalion rale 

7030 packcts/scc 
1660 packeis/sec 



Note that using DSA, the flow vertflcation rate is smaller 
than the flow signing rate. This is undesirable because 
receivers/verifiers arc generally less powerful than the 
signer/sender, e.g.» ihc receivers may be personal digital 
assistams or low-end notebook computers. Using RSA, 
the flow signing rate may not be high enough for some 
applications. Although wc can increase the flow signing and 
verification rates by using a longer period or a larger block 
size, neither option Is desirable. A larger block size increases 
the chaining overhead (packet signature size). A longer period 
increases the delay for signing reaMtme generated flows. 

Tu obtain a signature scheme belter than RSA and DSA 
for signing/verifying flows, wc propose several extensions to 
ihe Feigc-Fiat-Shamir (FFS) signature scheme. The extended 
scheme, called eFI-S, is presented in (he next section. The 
cFFS scheme has a very efficient signing operation (much 
more efficient than those of RSA and DSA) and a verificalion 
operation as efficient as that of RSA. A performance compart- 
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son of eFFS with five other signature schemes (including FFS, 
RSA and DSA) is given in Seciion IV. 

III. T»K cFFS Signature Scheme 

In Section IIKA, we first describe the basic FFS signature 
scheme [3], [4]. The cFFS signature scheme is derived from 
FFS with two kinds of extensions. Three extensions to speed 
up the signing and verification operations of FFS arc presented 
in Seciion lll-B. An extension to provide adjustable and 
Incremental signature verification is presented in Section lil-C. 

A. Basic FFS Scheme 

\n the basic FFS signature scheme with parami^ter {k^t) 
[3], [4]. each signer chooses two large primes p and and 
computes modulus n = pg. Then, the signer chooses k integers 
vi , • • • , (or A: iniegers « j , • • • , and computes , • - r *fc 
(or vi,- -jVit) by = v,"^modn. The signing key is 
' • * » and the verification key is {vi , • • • ^v^y n}. 

To sign message the s\%ncx docs (he following steps: 

1) choose t random integers. n,--,ri, between I and n, 
and compute x« if mod n for i = If* -it; 2) calculate 
the message digest l%{m,xi, - • * .art) where the message digest 
function /i(-) is public knowledge and the message digest is 
at least k x t bits long; let {^;} be the first A' x t bits of 
the message digest wliere i = 1. • - • , t, and j = 1, * • • , fc; 3) 
compute y/i = r; x (a*** x • • • x ) mod n for » = 1, • • • , t. 
The signature of message m consists of {y,} for x = 1, - • • ,t 
and [bij) for i = 1, • • - , t and j = 

To verify the signature of message m, a verifier computes 
Xi = yf x (vj" X K v^^)\\\odn for i = 
The signature is valid if and only if the first k x t bits of 
'^ir •• -.^c) are equal to the {bij) received. (It can l)c 
shown that z,- computed by the verifier is equal to at the 
signer.) 

The security level of FFS{^,t) depends on the following: t) 
the size of modulus n (i.e.* the size of the pfmtt p and q) and 

2) the value of product kU A system with a larger modulus is 
more secure, and a system with a larger ki product is more 
secure. If two sysx^ms have the same modulus and same kt 
product (but different k and I values), then their security levels 
arc about the same. 

Assuming \vi\ =e |n| and = |>t{, where \x\ denotes 
the size of z in bils» the signing^verification key size is 

+ 1] X |n| bits» and the signature sixe is < x |n| + A: x t bits. 
The signing/verificalion key size only depends on k^ but the 
signature si/e is proponionaJ to t. Ilius. for a fixed kt product » 
wc can reduce the signature size by using a smaller i (and a 
larger A;). For i = I, the signature size is minimized, but the 
signing/verification key size is maximized. Table H shows the 
signing/verification key size and signature size of FFS with 
SI 2-bit modulus. 

//. Extcitsumx ta Sfn'cJ up FFS 

I) Small Verification Key (small v-key}: In FFS, the sizes 
of si(>ning key componcms {j,} aiVcci the signing time, 
and the sizes of verification key components {v,-} affect the 
verification lime. An Improvement suggested in 112] is to 
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use the first k prime numbers as verification key components 
{vi}. However, since not every prime number p satisfies 
the condition that there exists an integer a such Uiat ^ 
p'^modn, we propose to use the first k prime numbers 
that satisfy this condition as verification key components.'' 
This extension reduces both the verification time and the 
verification key size. 

2) Chinese Remainder Theorem (crt): The signing opera- 
lion in FFS involves the computing of y,- = r< x (s*'* x 

"X 4**) tnod n. For n = pq, from the Chinese Remainder 
TKeorem, a signer can compute yi from and 6; using the 
following fonnula: yi = ((oi - 6^) x ^ x g*^ + 6i)modn 
where //" * = q'^modp, = r; x {s\^* X • • • x ^*'*') modp 
and 6< = r< X (aj'* x • • x «J'*)niod<?. Thus, instead of 
computing y« directly with multiplication operations in taodn, 
a signer first computes Oj and bi with multiplication operations 
in, respectively, mod p and mod q. Then Vi is computed from 
<ii and 6j. Since multiplication operations in mod p and modg 
arc more cflficient than in mod «. the signing lime is decreased. 

This Chinese Remainder Theorem improvement can only be 
used by a signer because knowledge of the factors of modulus 
n is required. A few hundred bytes of additional memory are 
needed for storing a few targe integers (for 512-bit modulus). 

3) Precompufan'on (precomp): A signer can further speed 
up the signing operation by using more memory. To illustrate 
the basic idea of this improvement, consider the signing 
operation with k = 4. To sign a message, a signer compute.^ 

= n X X • • X «5**)modn, for i = Since 
3i>-**,S4 do not change from message to message, and 

, " - * '^•4 are either one or zero, the signer can precompute 
and store the product (niodn) of every nonempty subset 
of {^i, • • ,54). tct Stj...64 denote the precomputed product 
Si X • • X sj'tnodn. Then, to sign a tnessage. the signer 
simply computes yi by x Sft.,.,.^.^ mod n. 

For large k, it is not practical to precompute the product 
(luod n) of every nonempty subset of {*i Instead, 
the signer partitions into smaller sets and prc- 

compulcs each of them. If each smaller set contains four in, 
then ii is a 4-bit precompuiation. Similarly, if each smaller 
SCI contains eight then ii Is an 8-bit prccomputaiion. For 
4-bit prccomputaiion with k = 128 and 512-bit modulus, 
a signer needs 10 store 12»/A x (2*^ - 1) =480 products. 
That is, additional memory of 480 x 612 bits or 31 kB is 
required. The additional memory required by 8-bit» 12-bit, and 
16-hil prccompulaiion arc 261 klJ, 2.88 MB, and 33.6 MB, 
respectively. 



pfiitficc. f(if A* up to t2«, ihc vcrificiHian key coiiMnmcnls {tu \ arc 
less ihan 2'**. ant) each c««)po(tcnl can be sioretS tn lb biis. 
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TABLE 111 

CFFS SlOWC TIME (MlUISECONDS) WITH 5U-8lT Moouuis 

I eFFS paiameter (it.t) 





(32,J) 


(32.2) 


(64.1) 


(32,4) 


(64,2) 


(128»1) 


basic FPS 


3.96 


7.S7 


■^41 


lUi 


14.35 


13.72 


small v-lcoy 


3.05 


7.84 


7.21 


15.63 


14.36 


13.72 


crt 1- small v^kcjr 


3.13 


C.20 


5.35 


12<44 


10.63 


9.78 


4-blt precomp -f- crt 4- small v-tey 


1.95 


3.64 


299 


7.61 


5.92 


5.08 


S>bit piemmp -f cri 'f small v-icey 


1.47 


2^ 


2.02 


5.67 


3.90 


3.14 



TABLE IV 

eFFS VBwncATTOH TIME (MILLISECONDS) Wnn 5l2-Brr MOOUtUS 



ePFS parameter (kj) 





(32.1) 


(32,2) 




(32,4) 


(04.2) 


(128,1) 


basic FPS 


3.65 


7.07 


7.12 


14.01 


13.63 


13.44 


flnnalt v-key 


0.33 


0.62 


0.43 


1.21 


0.81 


0.65 


4-bii precomp + anall v-key 


0.32 


0.60 


0.41 


1.18 


0.76 


0.S9 


B-ba precomp + small v-koy 


0.32 


0.59 


0.40 


1.14 


0,74 





Although a similar precomputation can be used in verifica* 
lion, il is not efTective with the small v-key extension. This is 
because when small primes are used as public key components, 
their products can be computed very efficiemly. 

4) Performance Comparison We implemenled the three 
speedup extensions using the large integer arithmetic routines 
from CryptoLib [8). Tables III and IV show the times for 
signing and verifying (witli Sl2>bit modulus) 128>bit message 
digests using difTcrent speedup extensions for dlHerent values 
of(A:,t).'^ The results were obtained on a Pentium il 300 MHz 
machine running Linux. Note that» for a fixed kt product, the 
signing/verification time is smaller when t is smaller. 

In the experiments to be reported in the balance of this 
paper, we used H-bii precomp + en + small v key for eFFS 
signing, and smuH v-key only for eFFS verification. 

C Adjustable and Incremental Verification 

In muhicasi or group communications, receivers typically 
have difVercnt amounts of resources, and the resources avail- 
able to a receiver for verification vary over time. It is thus 
desirable to have an adjustable and incremental signature 
verification operation. With this cxtaision« a signature can be 
verified at different security levels. An adjustable verification 
allows a receiver to verify a message at a lower security 
level using less resources. An incremental vcnfication allows 
a receiver to verify a message at a lower security level first, 
and later iiicrea.9e the .security level by using more resources 
(e.g., if the message is important). 

Since the security level of a signature scheme depends on 
lis parameters, e.g.. the modulus size, an obvious approach to 
provide adjustable and incremental verification is to use mul* 
liplc keys (with different modulus si/xs) to generate multiple 
.^gnaturcs for different security levels. To verify at a lower 
security level, the verification key with a shorter modulus size 
is used to verify the corresponding signature. This approach 
is simple but very inefficient. In the following, wc design 

''For basic FFS. we spticffieit signing key cofnponems {i>j). NMIkalion 
key compunenu {v,\ wen* chiiscn by Cryptoiab. 



TABLE V 

eFFS e-Lcva SiGNATuiu: Signino Tikcs (Miu.isgconds) 





kt product 






*t = 32 ike = 64 ki 


= 128 


Mcvel vigaature 


1.47 2.02 


3.14 


24evc1 8i«^a.ture 


2.87 


3.98 


4-level »gnaturc 




5.07 



an extension to FFS that provides adjustable and incremental 
venficatton efficiently. 

Our extension to provide adjustable and incremental veri- 
fication is to use t greater than one. and lo include {xi) for 
t = 2, " • ,Mn signatures. This is called a i-level signature}^ 
Tills extension is as secure as the original scheme because %i = 
y? X (tij** X • ' X t/^'* ) mod Ti for i = 2, • ' » ( can be computed 
easily from the original signature, which con.sists of (6i;} and 
{y,}, together with the verification key {vi, ■ • , Vfc.n} which 
is publicly known. 

To verify a t-level signature of message m at security level 
i oft (where I < t), a verifier docs the following: (I) compute 
Zi = y? x(vj*« X ... X *)inodn for i = 1, -,/ and (2) 
verify that *2 , • • • , -r/ are equal to 2:2 • * • * . . respectively, and 
the first it X t bits of /»(m,«i.xj, • .arr) are equal lo the 
[hij) received. 

To increase the verification security level from Ix to li. a 
verifier docs the following: I) compute Zi = y? x (vj*» x 
X t/^'*)niodn for 1 = ^1 + l,- -.^2» and 2) verify that 
-si,+i.- -.-5/, arc equal to xr^+i. • - ,2:1,, respectively. 

The size of n Mevel signature is A«-l-(2t - 1) x |nj bits. For 
512-bit modulus and product kt = 128, a Mevel signature is 
80 bytes and a 2-lcvel signature is 208 bytes. 

Table V shows dtfTerent Mevel signature signing times. 
For the same ki product, the .signing time incrca.scs as the t 
value increases. However, the signing time is still smaller than 
using muliiple keys lo implement dilTcrent .security levels. For 
example, the 2-level signature signing time, which is 3.98 ms 
for kt = 128. is smaller than the time to sign two (original 

'^Nole tint the urigiiwl (l-lcvet) »gra(ure di>cs ikk pruviilc jutjustAlitc and 
incremental vertncatfon. 
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TABLE VI 

cFFS iNCRCMnNTAL Verircatiok Times (MiixisttoNos) ruft L*i = 128. 
(a) 2-LEVEL StONATURE. (b) 4'Uvm. Skmaturc 



To 


level 1 


level 2 


fVomlev«tO 






FVom kvel 1 




0.40 



(a) 



To 


level I 


level 2 


level 3 


level 4 


FVom lew) 0 


0.34 


0.G3 


0.93 


1.22 


FVom level I 




0.30 


0.^ 


0.80 


Vtom level 2 






0.30 


O.$0 


Fhrni levels 








0.31 



<1») 



I -level) signatures, one for (fc.t) = (64,1) and ihc other for 
(Jfc, t) = (128, 1), which is 2.02 + 3.14 = 5.16 ras. 

Tabic VI shows the (incremental) verification times from 
one level lo a higher level for a 2-levcl signature and a 4-levcl 
signature with kt = 128. In particular, for a 2-lcvcl signature, 
a verifier can first verify a message at level I of 2 using 0.42 
ms processor lime, and later increase to level 2 (of 2) by using 
0.40 ms additional processor time. 

iV. Comparison With Other SiCNAruRH Schemes 
In this seciion, we compare eFFS(128, 1) to FFS(128, 1) as 
well as four other signature schemes available from CryploLib 
(81, namely: DSA [151. ElGamal [SJ, RSA [19], and Rabin 
(17). We compare their key and signature sizes* and signing 
and verification times. Then, we compare their signing and 
verification rates for 1024-bytc packets when each is used 
as ihe signature scheme in our How signing and verification 
procedures prcscnicd in Section IL Experiments were per- 
formed on a Pcmium II 300-MHz machine running Linux, 
Four different modulus sizes. 384, 512. 768, and 1024 bils. 
were used in the comparison. (Note that it is difficult to 
compare the security levels of differeni signature schemes even 
if they use the same modulas si/e.) 

A. Key and Stgnafurc Sizes 

Tabic VII shows the signing/vcnficaiion key and signature 
sizes. The signing keys are from 96 to 384 bytes in all schemes 
except FFS and eFFS whose signing keys are much larger, 
from 6192 lo 16512 bytes, Noie lhai a signing key is private 
lo a .signer. We do not expect ihc relalively large cFFS signing 
keys 10 pose a problem for sources/signers of packets.** 

In RSA and Rabin, verification keys arc from 48 to 128 
byics. In DSA, ElGamal. and cFFS, verification keys are 
slightly Uir^er» from 144 lo 404 bytes. Even for receivers with 
limited resources, we believe that a verification key as large 
as 400 bytes would not pose a problem. (Note that without 
the small v-kcy extension. FI'S verification keys arc as large 
as signing keys.) 

'^SiiL'ti signing keys ufv. indccii. uio large for small devices, sucf) as 
suuftcaiiis. Isiii II vt uiilikcly that Utcic ik vices would be soucvvs o( paclcct 
flow's or muilicxiis. 



TABLE Vll 

SlUNtHC Ki-V, V^RCATION KeY. AND SlOMATURE Sl/CS (BVTF^) OF DlFFCREhfr 
SICHA1VRC SCKEMRS. (a) SlGNlNO KEY SiZES (BYTES), (b) VcunCATMN 

Kuv Sizes (Bvtcs). (c) SkXATunE Sizus (Bytes). 



modulus site (biU) 
384 512 768 1024 



RSA 


96 


128 


192 


256 


Rabin 


dc 


128 


192 


256 


DSA 


136 


168 


232 


296 


BlGamal 


144 


192 


268 


384 


FFS(l2a,l) 


6192 


8256- 


12384 


16512 


eFPS(128.1) 


6192 


8256 


12384 


16512 


(e) 


RSA 


48 


64 


96 


126 


Rabiu 


4a 


64 


96 


128 


DSA 


164 


212 


308 


404 


ElGamal 


144 


192 


288 


384 


FFS(128,1) 


6192 


8256 


12384 


16512 


eFFS(m.l) 


304 


320 


352 


384 


(b) 


RSA 


48 


64 


96 


128 


Rabin 


48 


64 


96 


128 


DSA 


• 40 


40 


40 


40 


ElGamal 


96 


128 


192 


256 


FFS(12a.l) 


04 


80 


112 


144 


cFPS(l28.1) 


C4 


80 


112 


144 



(c) 



The signature of DSA is the smallest and is 40 bytes for all 
modulus siatcs. For all of the other schemes, the signatures arc 
larger and about Uie same size, 48 to 256 bytes. In particular, 
the .signature sizes of eFFS and the popular RSA are about 
the same. 

B. Signing and Verification Times 

Table VIII shows the signing and verification times for 
a l6-byie message (digest). DSA and ElGamal have been 
designed to achieve efficient signing (e.g., for use in smartcard 
appiicatiojis). and RSA and Rabin have been designed to 
achieve efficient vcrificatica From Table VlII, note that the 
signing operations of DSA and ElGamal. with limes from 3.9 
lo 18.9 m$» arc much more efficient than those of RSA and 
Rabin, with times from 6.2 to 95.9 ms. On the other hand, 
the verification operations of RSA and Rabin, with times firom 
0.14 to 1. 1 4 nis» are much more efficient than those of DSA 
and £IGamal. with limes from 5.1 to 350.3 ms. 

Note that the signing and verification operations of FFS 
are both inefficient. However, cFFS has a signing operation 
even more efficient than those of DSA and ElGamal, and 
a verification operation as efficient as that of RSA. This 
combination of the most efficient signing and highly efficient 
verification makes cFFS the bcsi choice for most applications. 

C Ftow Signing and Verification Rates 

Table IX shows the flow signing and verification rates of our 
flow signing and verification procedures (for l024-byi6 pack- 
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TABLE VII] 

StCNiNU AND VtauFYiNu- Times (MiLLisecuNos) of Dtn'b'R&'iT 
SitiNATURE SaiEMES, (a) Signing Time (M»j.tseDONOS). 
(b) VnRu-iCAnoN Time (Miluseconds). 

modiihiA floe (bits) 



KSA 
Rabin 
DSA 
ElGamal 
FFS(128.X) 
eFPS(12B.l) 



3B4 512 768 1024 



6.2 
lU 

5.1 
M 
2.3 



12.7 
19.5 
5.6 
6.8 
13.7 
3.1 



36.2 
47.5 
10.2 
12.3 
22.9 
52 



7d.4 
95.9 
16.3 
18.9 
38.S 
8.2 



modulus 8ixc (bils) 





384 


512 


768 


1024 


RSA 


0.26 


0.40 


0.70 


l.l 


lUbin 


0.14 


0.20 


0.38 


0.66 


DSA 


5.1 


7.6 


14.7 


24.2 


SlGamai 


24.4 


51.9 


157.5 


350.3 


FFS(128.I) 


8.5 


134 


22.} 


37.3 


eFFS(m.l) 


0.53 


0.65 


0.82 


1.1 



(b) 
TABLE IX 

Flow StUNwc; ani> Vfjiificatkin Ratrs (PACKen/S) roR {024 llvic Facki^is. 
D^^. Two Thes Chaining, and Block Sia- Sixteen, (a) Ftow Skjwng 
Rate (Packuts/s). (b) Flow VewRCAnoN Ratc (PACXtTS/S). 





modulus i 


B«e (bits) 




3S4 


612 


768 


1024 




1940 


1090 


413 


193 


Rabm 


1200 


739 


321 


163 


DSA 


2760 


2140 


1320 


874 


ElGamal 


2320 


1850 


U40 


740 


FFS{128.1) 


1550 


1070 


624 


395 


cPFS( 128.1) 


3920 


3140 


2160 


1610 


(a) 




moduiutt size (bits) 




384 


512 


768 


1024 


nsA 


7480 


7030 


6060 


5290 


Ilabui 


7960 


7610 


7010 


6430 


DSA 


2270 


1660 


949 


609 


mCanuil 


600 


295 


99 


45 


KFS(128.1) 


1590 


1150 


033 


419 


eFFS(l28J) 


6640 


0370 


5760 


5250 



(b) 



cu, dcgrcc-lwo ircc chaining, block size sixieen, and 100% 
of processor time of a Pentium il 300*MH/, machine). Both 
DSA and ElGamal have tow flow verification rates, rendering 
them inappropriate for receivers with hmiled resources, such 
as personal digital assistants and low-end notebook computers. 
Both RSA and Rabin have low flow signing rates, rendering 
them inappropriate for real-time generated flows, such as live 
video/audio applications. By compari.son, cFFS provides high 
flow signing rales suitable for rcal*timc generated flows while 
its flow verification rates arc also very high. 

V. Conclusion 
Wc investigated the problem of signing/verifying dclny- 
sensitive packet flows to provide data authenticity, integrity. 



and nonrcpudialion for fnlcmci applications. We have designed 
flow signing and verification procedures, based upon a tree- 
chaining technique, to meet the following requirements: I) 
flow signing is efficient and, for real-time generated flows, 
delay-bounded; 2) flow verification is efficient {for receivers 
with limited resources); 3) packets in a flow arc individually 
verifiable (for best-efr<nt multicast delivery); 4) packet sig- 
natures are small (for a small communication overhead); and 
5) verification at a receiver is adjustable to difFereni security 
levels and can be carried out mcrcmchtally (for receivers with 
limited resources). 

We implemented our flow signing and verification proce- 
dures and performed experiments to compare different chain- 
ing techniques. From experimental results, we recommend the 
use of degree>two (binary) tree chaining since it requires the 
smaUest packet signature size (i.e., smallest commumcaiion 
overhead) while its signing and verification rates arc compara- 
ble to the rates of other chaining techniques. Our flow signing 
and verification procedures are. very efficient and achieve one 
to two orders of magnitude improvement compared to the 
sign-each approach. 

Since signed packets in our procedures ar« individually 
verifiable, the procedures can be used to reduce the workload 
of any machine that sends out a large number of signed packets 
10 one or more destinations. There is no requirement that these 
packets belong to flows. However, for packets that belong to 
a flow, the woricload of the flow's receivers) is also reduced. 

To further improve our procedures, we propose several ck- 
lensions to the Feigc-Fiat-Shamir digital signature scheme (3), 
[4] to speed up both the signing and verification operations, 
as well as to allow adjustable and incremental verification. 
The exiendcd scheme, called eFFS, is compared to four other 
digital signature schemes, RSA (19|, Rabin [17), DSA (15), 
and ElGamal (61, on the same computing platfonn (Pentium 
M 300-MHz machine running Linux). 

The signing operation of eFFS is by far the most effident 
of all the schemes compared. The verification operation of 
eFFS is as efficient as that of RSA (tie for a close second 
behind the verification operation of Rabin). In addition to 
efficient signing and verification, we have extended the eFFS 
scheme to allow a receiver to efficiently cairy out adjustable 
and incremental verification. Such a capability is useful for 
large-scale multicast applications with a variety of receivers 
including some with limited resources. 

APl>l;Nl>IX 

Flow VtRtFiCATiON Prockduru 

procedure flowvcrify() 
for each received packet 

if the block signature sign(root) in the packet signature 
is new then 

/• this is the first received packet in the biock V 
compute the packet digest; 
compute each ancestor of the packet digest 

as the message digest of its children; 
let roof be the computed block digest; 
if (vcrify(mnf', si^n{r\)Ot)) * false) then 
the packet is not verified 
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else 

the packet is verified; 

cache all compuled nodes and their children 
as verified 

endif 

else I* this is not the first received packet in the block •/ 
compute the packet digest; 
tf (packet digest has been cached) then 

if (compuled packet digest its cached value) 

then the packet is not verified 
else 

the packet is verified 
endif 
else 

compute all noncached ancestors or the 

packet digest; 
let node be the highest node computed; 
compute the parent of node; 
if (computed parent / its cached value) then 

the packet is not verified 
else 

the packet is verified; 

cache all compuled nodes and their children 
as verified 
endif 
endif 
endif 
endfor 



[12) S, Micalt and A. Shamir, "Ao improvcniem <m die Ptai-Shamir identifi- 
cation and wgiwlure whemc," in 44fvanccs in 

1990, pp. 244-247. 
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